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REMARKS/ARGUMENTS 

Status: 

In the Office Action dated April 1, 2008, the status was indicated as: 

1 ) claims 1-130 were pending, 

2) claims 1-39, 54-69, 73-106, 1 17-120, and 125-130 were withdrawn from 
consideration, and 

3) claims 40-53, 70-72, 107-1 16 and 121-124 were rejected. 
Election/Restrictions 

In the Office Action, restriction to one of the inventions was required as indicated below: 

1 . Restriction to one of tlie following inventions is required under 35 U.S.C. 121 : 

I. Claims 1-39 and 82-106, drawn to a telephone voice response based cable television 
provisioning system, classified in class 725, subclass 122. 

II. Claims 40-53, 70-72, 107-116 and 121-124, drawn to a website based cable television 
provisioning system, classified in class 725, subclass 110. 

III. Claims 54-59, 73-81 and 130, drawn to a database storing cable service provider records, 
host type data and service location data, classified in class 707, subclass 104.1. 

IV. Claims 60-65 and 1 17-120, drawn to a STB based cable television provisioning 
system, classified in class 725, subclass 37. 

V Claim 66-69 and 125-129, drawn to a retail store based cable television 
provisioning system, classified in class 705, subclass 1. 

In response to the election requirement, Applicant elects without traverse the claims of Group II, 

comprising claims 40-53, 70-72, 107-1 16, and 121-124, which is consistent with a telephone call 
with the Examiner as reported in the Office Action. The non-elected claims are shown in this 
amendment as withdrawn. 
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Claim Rejections under 35 U.S.C. 112 

In the Office Action, claims 52 and 121 were rejected for reciting the limitation "the 
enhanced services system" in lines 1 and 15, respectively based on insufficient antecedent 
basis. Applicant has amended claims 52 and 121 to correct this deficiency, and requests the 
rejection be withdrawn. 

Claim Rejections under 35 U.S.C. 103 

In the Office Action, Claims 40-53, 107-1 16 and 121-124 were rejected under 35 
U.S.C. 103(a) as being unpatentable over Borelli et al. (US Patent Application Publication 
2006/0020525), herein "Borelli," in view of Tamura (US Patent Application Publication 
2003/0048380), herein "Tamura." 

Background Discussion 

Prior to addressing the claims individually, Applicant brings to the Examiner's attention 
related applications which are identified in the specification (page 1) in the spirit of fiiU 
disclosure. Applicant has also provided, or will provide shortly, an IDS comprising 
prosecution related documents in addition to prior art identified in related applications for the 
Examiner's consideration. Some of the same or similar limitations in the present claims are 
found in the claims of the other applications, some of which have matured into patents. 

Along this line. Applicant desires to provide background information regarding certain 
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aspects of the disclosure, which are elaborated in discussing the individual claims that follow. 
Because these aspects are repeated in the various claims, it is appropriate to address certain 
aspects up front, prior to dealing with the individual claims. As noted in the Summary section 
of the present specification, the specification discloses a capability which allows new 
capabilities in a host to be utilized. This is accomplished in part by a mechanism for the 
enhanced service system in the cable network to use new messages and parameters for 
controlling and configuring these new capabilities in the host. (Specification, ^1 57.) In the 
prior art, devices connected to a cable network implemented a defined set of capabilities, and 
hence there was no need to distinguish which set of capabilities the host incorporated, or which 
messages were used to interact with the host. Even if the network were able to download 
information to a set top box to recognize new messages, it was presumed that the set top box 
had a certain platform that allowed it to do so. Further, the set top box would then still be 
viewed by the network as implementing a defined set of capabilities. 

In the present disclosure, the cable network is capable of adapting to new and different 
capabilities in a host. Doing so involves explanation of various limitations found in the elected 
claims, such as: "host type," "host identifier," "host file," and "host-specific configuration 
message." As indicated in the specification, a "host" includes, but is not limited to, set top 
boxes or televisions connected to a cable system, which incorporate new capabilities relative to 
the existing capabilities found in existing set top boxes. (Id, at T| 65.) 

It is possible that different brands of hosts will have different capabilities and use 
different messages for controlling new, enhanced services. In fact, it is expected that the 
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capabilities of different brands of hosts may not be exactly the same. For example, a new 
service may require a new capability in the host which involves configuring a personal video 
recorder capability ("PVR"). One host may have a maximum of 3600 minutes (or 60 hours) of 
recording time, while another may have 14,400 minute (240 hours) of recording time. These 
differences reflect different storage capabilities of different host manufactures, or could reflect 
different capabilities of different models from the same host manufacturer. Further, the 
messages used by the service provider for configuring the host may be different (both between 
different manufactures, and different between different models from the same manufacturer). 
Presently, different set top boxes are often incompatible between different cable providers. 

Thus, in order to be compatible, it is necessary for the enhanced services system in the 
cable services provider to know what "host type" is used. Typically, the host type is identified 
by identifiers indicating the host manufacture and model. (Id. at 74.) This is not the same as a 
"host identifier," which identifies a particular device but may not necessarily identify the make 
and mode. (Id. at 163.) Typically, a host, such as a STB, is identified by an address, which can 
include a MAC level address. (Id. at 14.) Thus, a "host type" does not identify a particular 
host, but a "host identifier" does. However, a "host identifier" may not by itself indicate the 
particular "host type." However, it is presumed that every particular host device is associated 
with a host type (e.g., it is made by some manufacturer). 

The specification indicates that different message formats may be used to configure a 
host, and the message formats depends on the host type. Further, the meaning of the messages 
themselves may be different in that the fimction performed may vary for different host types. In 
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order to facilitate the anticipated variety of message formats and meanings, the concept of a 
"host file(s)" is developed. Typically, a host manufacturer provides the "host file" to provide 
information for a particular host type which they manufacture. The host file(s) include a "host 
profile" file which describes the fimctionality and capabilities of the host. For example, it 
could indicate that the host has a maximum recording capability of 240 hours. Another type of 
host file is a "host protocol file" which provides in part the protocol messages (formats) for 
configuring a host. (Id. at 67.) The host file may be provided by the manufacturer of the host 
(hence, typically, but not always, the host type is identified by a manufacture and model 
identifier). Using the "host file(s)" allows the enhanced services system to properly configure 
the host for a given service. 

To use an analogy, an automobile may have a serial number. If repairs to the engine arc 
necessary, such as replacing a part on the engine, it is not sufficient to merely know the serial 
number of the car. It is necessary to know what type of engine is present (because there may 
be 4 or 6 cylinder engines that were available as options for that particular make and model 
car). Thus, merely knowing that a new piston is required is not sufficient to identify a 
replacement part for the automobile; the make/model of the automobile must also be known. 

In the prior art, all set top boxes conformed to a single communication standard and had 
a common set of capabilities. The network communicated with all hosts in the same manner. 
In some instances, new software could be downloaded to the set top box by the network, but 
after doing so, all communication by the network then involved the same standard messaging. 
Hence, all set top boxes conformed to a single communication standard. As it can be seen, the 
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serial number of the set top box was not needed by the network to ascertain how to 
communicate with the set top box. At most, the serial number was required to authenticate the 
set top box and it would determine whether the network would communicate with the set top 
box or whether communication was authorized. (E.g., should that set top box be configured for, 
or be allowed to request, movies on demand?) However, when there are different protocols 
that can be used for communicating with different type of hosts on a cable system, knowing the 
host identifier by itself is not sufficient for the cable system to know how to communicate with 
that particular host. 

Somehow, the host make/model (to borrow terminology from the prior analogy) must 
be ascertained. This can occur in various ways, including mapping the identifier to a 
makc/modcl in a database accessible by the network, or having the host itself directly transmit 
its make/model information. In the former embodiment, the host identifier information could 
be used to identify a particular subscriber and corresponding subscriber profile. There could be 
information in the subscriber profile indicating the host type that the subscriber is using. Once 
the host type is known, the proper host files can be identified and used to determine how to 
communicate with that particular host. (See, e.g.. Figure 12.) 

Because prior art systems largely presume a common communication protocol, the prior 
art of record does not disclose the limitations recited in the claims such as: "host type," "host 
identifier," "host file," and "host-specific configuration message." Applicant notes that these 
terms are to be construed as set forth in the specification, and that the prior art does not disclose 
these limitations as properly construed. 
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Discussion of Specific Claims 
Claims 40-50. 

Claim 40 is an independent claim, with claims 41, 42, and 43-50 depending therefrom. 
Claim 40 has been amended so as to not separately recite "a computer." Further, claim 43 is 
cancelled, as its contents has largely been incorporated into claim 40. Hence, independent 
claim 40 now recites the limitation "said ESS using said host identifier to ascertain a host file 
associated with a host type, said host type determined in part by said host identifier, the host 
file used to identify a host protocol file used for generating a message for provisioning a host 
identified by said host identifier." 

Applicant submits that these limitations are not found in the prior art, and focuses on the 
reasons presented in the Office Action regarding claim 43. The Office Action states: 

Consider claim 43, Borelli combined with Tamura, as in claim 40, clearly teaches provisioning a set- 
top box in response to a message containing service related data and a host identifier. 

Tamura further teaches selecting a host file associated with a host type. ([0027]) 

Therefore, at the time the invention was made, it would have been obvious to one with 
ordinary skill in the art to modify the system of Borelli by selecting a host file associated with a 
host type, as taught by Tamura, for the benefit of providing system specific provisioning of the set- 
top box (see [0004] Tamura). 

Given the previous discussion of "host file" and related terms, it should be clear that 
Tamura does not disclose selecting a host file associated with a host type as alleged in 
paragraph 27. Specifically, note that Tamura states the following: 

"At 310, once communication is established between the STB 104 and the service provider, 
identifying information such as serial number, device type, smart card identifier, etc. is sent from the STB 
to the service provider head end. The service provider responds at 314 with system information required 
by the STB 104 in order properly communicate with the service provider when operational." [sic] 
(Tamura, par. 27, emphasis added.) 

A carefiil reading indicates that "the service provider responds at 314 with system 

information required by the STB 104 in order [to] properly communicate with the service 
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provider when operational." Thus, the service provider presumably downloads ("responds with 
system information") information to the STB in order to allow the STB to properly 
communicate with the service provider. This reflects the prior art of the system downloading 
information (e.g., a standard message set) to be used by the STB. In other words, the service 
provider provides information to the STB which the STB must use to communicate properly. 
This is consistent with all the STB using a standard message set in order to communicate with 
the service provider. Tamura teaches away from the network provider obtaining information 
and adapting to the particular message set used by the STB. In other words, Tamura is 
predicated on the set top box adapting to the network service provider, not the network service 
provider adapting for a particular set top box. 

In particular, there is no teaching of the service provider in Tamura using the 
identifjdng information from the set top box to "ascertain a host file." Indeed, there is no such 
disclosure of the service provider obtaining a "host file," or using the host file "to identify a 
message for provisioning a host identified by said host identifier." As noted above, the "host 
file" comprises a host profile file and a host protocol file, and neither aspect is taught or 
suggested by Tamura. 

Claims 51-53. 

Claim 51 is an independent claim, with claims 52 and 53 depending therefrom. Claim 

51 is amended so as to not recite a separate "computer". 

Claim 51 also recites various limitations involving "host type identifier," such as: 

• "wherein said service related input data comprises an indication of the user's host 
type, the ISPG configured to generate a first provisioning message having a first 
format including the cable subscriber location data and said indication of the 
user's host type", and 

• "selecting a cable service provider identifier compatible with said subscriber 
location data and said indication of the user's host type, the serviceability 
database fiirther capable of generating a second provisioning message including at 
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service related input data and at least one associated host type identifier." 

The above limitations recite the role of the "indication of the user's host type" in provisioning 
the host. Specifically, the information of the user's host type is indicated and used to ascertain 
what service provider is compatible with the user's host type. 

Borelli is acknowledged not to disclose receiving a host identifier (Office Action, page 
8.) Rather, Tamura is relied upon for that teaching. Presuming for sake of argument that 
Tamura does disclose this limitation, Borelli does not disclose using the host type information 
to select a particular service provider. Because Borelli does not disclose receiving this 
information, Borelli does not disclose using that information to process provisioning requests. 
Specifically, Borelli does not select a particular service provider using the user's host type as a 
basis. 

As noted elsewhere, Tamura presumes the network provider will download information 
allowing the set top box to communicate properly with the network. Tamura does not presume 
that the network will adapt so as to communicate properly with the set top box. Thus, Tamura 
and Borelli do not disclose using the host type to ascertain whether the user can obtain a 
particular service from the service provider. Thus, neither reference would contemplate 
identifying a particular service provider that could be compatible with the host type. 

Because Borelli does not disclose a service provider selected based on the user's host 
type, there is no disclosure of a serviceability database "wherein each cable service provider 
identifier is further associated with at least one host type identifier." Further, the Office Action 
is silent on this limitation, so that even if it is presumed that the Tamura is used to teach 
sending this information, Borelli still does not disclose using it to associated each cable service 
provider wdth at least one host type identifier. 

Finally, the combination of Tamura and Borelli is deficient because Tamura is relied 
upon for its teaching of the set top box sending the host type information to the network. In 
contrast, claim 5 1 recites "the ISPG configured to receive from the computer both said service 
related input data and cable subscriber location data wherein said service related input data 
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comprises an indication of the user's host type." Specifically, the claim does not recite receiving 
the information from the set top box, but that the ISPG receives it from a computer. Thus, the 
combination of Tamura and Borelli does not render obvious the limitations recited in claim 5 1 . 

Claims 107- 116. 

These method claims involve independent claims 107, 108, 113, and 1 14. 
Claims 109 -1 12 depend from claim 108, and claims 115-116 depending from claim 1 14. 
Applicant is focusing on the independent claims only for expediency. 

Claim 107 has been amended to recite the limitation "an enhanced services system 
comprising a database storing a file maintaining an association of cable subscribers and their 
respective host types." 

This reflects an embodiment where the enhanced services system has a database that 
allows determination of each cable subscriber's respective host type. This is related to the 
aspect of requiring information of the subscriber's host type in order to "generat[e] a host- 
specific configuration message based on a host protocol file wherein the host protocol file is 
associated with the host t5^e." 

The Office Action admits that "Borelli does not explicitly teach transmitting a host 
identifier to the enhanced services system." In one embodiment of the present invention, the 
host identifier is used to ascertain what host file, and hence which host protocol file, is used to 
communicate wdth the host. Borelli does not disclose "host files" as Applicant uses the term in 
the present specification. Further, if Borelli does not disclose receiving the host identifier, how 
can Borelli then disclose processing the host identifier to ascertain what host file (and which 
host protocol file) to use? The answer is that Borelli does not require the host identifier in 
provisioning a set top box because Borelli does not require a host protocol file to create the 
"host-specific configuration message." Borelli is designed to operate on present-day cable 
systems wherein the set top box is presumed to be compatible with the cable system. 
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The Office Action states that Borelli discloses a "host file" and a "host-specific 
configuration message based on a host protocol file" based on paragraph 70 of Borelli, shown 
below: 

[0070] The Provisioning IVIanager 48 may furtlier cooperate witli tlie Product catalog 30 and an 
IP Address Rules Server 60 to determine the proper IP subnet(s) for the service(s), plan selected. If 
multiple subnets are determined to be available, the Network Provider's 14 allocation mechanism is 
responsible for handling the selection of the appropriate subnet during the DHCP lease request 
process. In connection with the allocation, the Provisioning Manager 48 should be directed to refer to 
the Product Catalog 30 for the list of discrete services that need to be configured to complete the 
customer's registration process. The Provisioning Manager 48 can then institute the necessary 
provisioning actions at a provider/device level and complete the necessary steps to provision the user 
within the ISP's and Network provider's networks in the manner discussed previously. For example, if 
providers require custom software installs, this is noted and returned to the ISP website as a complete 
list to be executed by the ISP's systems. The completed list of providers and all identity/download 
information is returned as an XML message to the ISP systems to be processed by the ISP. The ISP 
handles the presentation of this information. 

The above paragraph does not disclose "host file(s)," nor "generating a host-specific 

configuration message based on a host protocol file" as recited in claim 107. In fact, the cited 

text states "[t]he Provision Manager 48 can then institute the necessary provisioning actions at 

a provider/device level and complete the necessary steps to provision the user with the ISP's 

and Network provider's networks in the manner discussed previously." This does not disclose 

how the network provider actually provisions the user. Nor does the referenced text disclose 

that the network provider uses a "host protocol file" for generating a "host-specific 

configuration message." 



Claim 108 has been amended to conform more closely with terminology used in the 
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specification. Claim 108 recites an embodiment where the enhanced services system selects a 
"host file" that is "associated with both the cable service data and a host type wherein the host 
type is determined fi-om the host identification data." 

Although the Office Action refers to the same reasoning for claim 107, it remains as 
noted above that Borelli and Tamura do not disclose using the data identifying the set top box 
or device type to select a particular file, much less a "host file" as developed by the invention. 

It is facially deficient that the combination of Borelli and Tamura teach the limitations 
in 108 (as well as 107 or other claims). The Examiner states that transmitting the host identifier 
in Tamura meets the missing claim limitation. However, the claim requires using the host 
identifier to ascertain a particular host file, in order to adapt to the particular capabilities and 
message set of the host. There is no such disclosure in Borelli of doing this processing, hence it 
is no surprise that Borelli does not disclose receiving a particular host identifier. Borelli does 
not need a host identifier, because Borelli does not select a host file in order to ascertain how to 
communicate with a particular host on a cable provider's network. In fact, Applicant's 
perspective of Borelli is that it discloses a "broker" for interacting with various existing 
network service providers, and does not address how the provisioning must occur between the 
particular service provider and the device attached thereto. (See Borelli, par. 8.) 

Claim 113. 

The Office Action refers to the reasoning in rejection claim 107, and hence the response 
indicated above is incorporated by reference. 

Applicant also submits that there is no disclosure indicated by the Office Action as to 
providing a "provisioning message including the host type data" in Borelli. Since the Examiner 
admits that Borelli does not disclose the "host type" (but relies, instead on Tamura), then it 

would follow that the provisioning process in Borelli cannot be based on a received host type, 
nor generating a provisioning message including the "host type data." Applicant notes that 
Tamura sends the host type data to the network, and there is no disclosure pointed to in Tamura 
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where the host type data is sent from an ISPG to the destination, where the provisioning 
message include the "host type data." Rather, the Examiner relies on Borelli for this aspect. 
Hence, it would appear that neither Borelli nor Tamura disclose the limitations as claimed in 
claim 113. 

Claim 114 

Claim 1 14 has been amended to reflect an embodiment where in addition to the 
subscriber's location and desired service, the host type is used in provisioning a service. 

The Office Action refers to the same reasoning in rejecting claim 107, but Applicant 
notes that the basis for such is inapplicable to the present claim. 

First, the Office Action admits that "Borelli does not explicitly teach transmitting a host 
identifier to the enhanced services system." (Office Action, page 9.) For this, Tamura is relied 
up. Tamura states that "once communication is established between the STB 104 and the 
service provider, identifjdng information such as serial number device type, smart card 
identifier, etc. is sent from the STB to the service provider head end. The service provider 
responds at 3 14 with system information required by the STB 104 in order to properly 
communicated with the service provider when operational." (Tamura, par. 27.) 

The present claim recites "host type," not "host identifier." Applicant submits that just 
as Borelli does not disclose a transmitting a host identifier, neither does Borelli disclose 
transmitting a "host type." However, Applicant notes that Tamura discloses the STB could 
send "device type" information. However, it is not clear that "device type" conveys the same 
information as a "host type." Even if Tamura discloses transmitting a "host type," which 
Applicant does not concede it does, Borelli does not disclose processing the host type for 
purposes of "generating at least on provisioning message to a service provider." In fact, there 
is no processing at all identified in the Office Action where Borelli processes action different 
based on "host type", because Borelli does not disclose using "host type" at all. 

In summary, just because Tamura may disclose sending "host type" information, there is 
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no disclosure in Borelli that the host type is used in "generating a message to a serviceability 
database including the cable subscriber location data and the host type." Nor is there any 
disclosure in Borelli that the host type is used in generating a provisioning message "wherein the 
at least one provisioning message includes the cable subscriber identification data, the host type, 
and service offering identifier." In fact, Borelli appears to operate with present data cable 
systems where the set top boxes are all presumed to be compatible with the cable network, and 
there is no reason why the tj^e of set top box is relevant in the provisioning process. 

Claims 121-124 

Claim 121 is an independent claim, with claims 122-124 depending therefrom. 

Claim 121 recites as its first step: "receiving at a provisioning input system a host 
type. . . ." The indication of the host type is necessary for the performing the subsequent step of 
"selecting at the enhanced services system a host protocol file based on the service offering and 
the host type." Applicant submits that neither Borelli nor Tamura disclose "a host type" which 
is used to select a "host protocol file." In fact Tamura is relied upon for sending a "host type" 
and this is combined with Borelli, because, as the Examiner admits, Borelli does not disclose a 
"host type." If Borelli does not disclose a "host type", how can Borelli disclose using the 
received host type to select a host protocol file? 

In fact, the Office Action refers to the same reasoning for claim 40, but claim 40 as 
examined did not recite a "host protocol file." Thus, there is no reasoned basis for using the 
Office Action's response for claim 40 to demonstrate how Borelli disclosed use of a "protocol 
file." 

Further, claim 121 also recites other aspects which are not disclosed in Borelli, 
specifically: 

1) "determining a cable network provider for the user based on the location data 
and the host type," and 

2) "determining a service offering associated with the cable network provider 
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wherein the service offering is further associated with the host type." 

Borelli does not disclose determining a cable network provider or a service offering based on 
the host type. Borelli does disclose using the user's street address to determine if access to a 
network provider is possible (see, e.g., par. 37-47). Borelli also discloses that if "the potential 
customer is qualified for one or more types of access to the Network, a query (300) is made to 
the Product Catalog Server 30 to retrieve (400) a list of offerings available, if any at the 
specified location for the class of customer." (Borelli, par. 48.) However, BoreUi does not 
disclose that the host type is used to determine a cable network provider, or that the host type is 
fijrther associated with the service offering. In summary, Borelli uses the subscriber's location 
to ascertain what type of access is possible, and then based on that access, what services are 
possible. 

As the Examiner admits elsewhere in the Office Action, Borelli does not disclose a 
"host type." If Borelli does not disclose a "host type," then how can Borelli disclose using the 
host type to determine a cable network provider based on the host type? Further, if Borelli does 
not disclose a host type, then how can Borelli disclose determining a service offering that is 
"associated with the host type"? Tamura cannot be relied on this, since Tamura does not 
disclose, and is not relied upon, for the network processing of the information received fi"om 
the terminal. Applicant notes that it is expected that Borelli would not disclose using the host 
type in such a way, because Borelli operates in the same way as prior art systems wherein the 
user's equipment is not determinative of the service or service provider. 

CONCLUSION 

Applicant submits that the independent claims recite various limitations that are not 
found in Borelli, nor in Tamura. Consequently, Applicant submits the elected independent 
claims are now in a condition for allowance, and that rejections be withdrawn. Further, because 
the dependent claims depend fi-om patentably distinct claims, the dependent claims are now in a 
condition for allowance as well. 
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It is not believed that extensions of time or fees for net addition of claims are required, 
beyond those that may otherwise be provided for in documents accompanying this paper. 
However, in the event that additional extensions of time are necessary to allow consideration of 
this paper, such extensions are hereby petitioned under 37 CFR § 1.136(a), and any fee required 
therefore (including fees for net addition of claims) is hereby authorized to be charged to Deposit 
Account No. 16-0605. 

RespectfiiUy submitted. 
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